A major reason for the high cost of test equipment is the specialized nature of conventional tester architecture. Each tester manufacturer has a number of tester platforms that are not only incompatible across companies such as Advantest, Teradyne and Agilent, but also incompatible across platforms within a company, such as the T3300, T5500 and T6600 series testers manufactured by Advantest. Because of these incompatibilities, each tester requires its own specialized hardware and software components, and these specialized hardware and software components cannot be used on other testers. In addition, a significant effort is required to port a test program from one tester to another, and to develop third party solutions. Even when a third party solution is developed for a platform, it cannot be ported or reused on a different platform. The translation process from one platform to another is generally complex and error prone, resulting in additional effort, time and increased test cost.
Another problem of the specialized tester architecture is that all hardware and software remain in a fixed configuration for a given tester. To test a device-under-test (DUT) or an IC, a dedicated test program is developed that uses some or all of the tester capabilities to define the test data, signals, waveforms, and current and voltage levels, as well as to collect the DUT response and to determine whether a DUT has passed or failed a test.
An open architecture test system provides a solution to the above problems of the traditional test system. An example of an open architecture test system is described in U.S. application Ser. No. 10/772,434, “Method and Structure to Develop a Test Program for Semiconductor Integrated Circuits”, which is incorporated herein in its entirety by reference. The open architecture test system can be configured to support a wide variety of vendor hardware test modules and their corresponding DUTs.
However, one of the challenges in implementing such an open architecture test system is that there may be multiple versions of tester operating systems (TOSs). In addition, each vendor hardware test module may have multiple versions and each version of the vendor hardware test module may have its corresponding versions of software components. The versions of the tester operating systems, vendor hardware test modules, and software components need to work together seamlessly in order to run tests on the vendor hardware test modules. Therefore, there is a need for a modular test system that can manage multiple vendor hardware test module versions, software components versions, and TOS versions for testing DUTs using the wide variety of vendor hardware test modules.